-
Notifications
You must be signed in to change notification settings - Fork 969
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(shwap/bitswap): Blockstore.GetSize: getting size with no compute #3894
Conversation
2bef3ec
to
ad5a7b5
Compare
If GetSize is used only for prioritisation of bitswap server hanling of requests, perhaps don't really need to calculate sizes. Alternative could be to return const values depending on type of the cid and our estimate of proper priority / load of handling. For examples:
This would allow us to remove the need for heavy reads to get the priority for serving of requests and will easy the pressure on cache. |
In sync, we agreed to keep the Size computation based on real blocksize to be safe. Making all sizes fixed to max block size may limit bitswap's throughput for small block sizes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need additional tests for this? Are the changes already covered by some test suite?
It is covered |
Disabling the automerge for now. I want to do another change here |
f5c4f4c
to
fc1e188
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utack
fc1e188
to
8c953dc
Compare
e32030b
to
8fc2000
Compare
…3894) Bitswap prioritizes peers based on their active/pending work and the priority that peers set for requests(work) themselves. The prioritization happens on the `Get` operation of `Blockstore` not `GetSize`. However, we currently do the most expensive work in `GetSize` followed by `Get`. It is still part of the same WANT_BLOCK request(since #3813), and `GetSize` work is usually cached for `Get` to catch it. Still, the prioritization makes it so that the time between `GetSize` and `Get` can be pretty long, inducing cache misses and redoing the same work again, which is confirmed by profiles. Also, doing the expensive part in `GetSize` avoids Bitswap server's rate limiting. All this brings the need to make `GetSize` as lightweight as possible, leaving actual proof computed to `Get`. This PR achieves this by defining a constant max block size for every type block. --- 🎱 mb blonks certified
…3894) Bitswap prioritizes peers based on their active/pending work and the priority that peers set for requests(work) themselves. The prioritization happens on the `Get` operation of `Blockstore` not `GetSize`. However, we currently do the most expensive work in `GetSize` followed by `Get`. It is still part of the same WANT_BLOCK request(since #3813), and `GetSize` work is usually cached for `Get` to catch it. Still, the prioritization makes it so that the time between `GetSize` and `Get` can be pretty long, inducing cache misses and redoing the same work again, which is confirmed by profiles. Also, doing the expensive part in `GetSize` avoids Bitswap server's rate limiting. All this brings the need to make `GetSize` as lightweight as possible, leaving actual proof computed to `Get`. This PR achieves this by defining a constant max block size for every type block. --- 🎱 mb blonks certified
…3894) Bitswap prioritizes peers based on their active/pending work and the priority that peers set for requests(work) themselves. The prioritization happens on the `Get` operation of `Blockstore` not `GetSize`. However, we currently do the most expensive work in `GetSize` followed by `Get`. It is still part of the same WANT_BLOCK request(since #3813), and `GetSize` work is usually cached for `Get` to catch it. Still, the prioritization makes it so that the time between `GetSize` and `Get` can be pretty long, inducing cache misses and redoing the same work again, which is confirmed by profiles. Also, doing the expensive part in `GetSize` avoids Bitswap server's rate limiting. All this brings the need to make `GetSize` as lightweight as possible, leaving actual proof computed to `Get`. This PR achieves this by defining a constant max block size for every type block. --- 🎱 mb blonks certified
Bitswap prioritizes peers based on their active/pending work and the priority that peers set for requests(work) themselves. The prioritization happens on the
Get
operation ofBlockstore
notGetSize
. However, we currently do the most expensive work inGetSize
followed byGet
. It is still part of the same WANT_BLOCK request(since #3813), andGetSize
work is usually cached forGet
to catch it. Still, the prioritization makes it so that the time betweenGetSize
andGet
can be pretty long, inducing cache misses and redoing the same work again, which is confirmed by profiles. Also, doing the expensive part inGetSize
avoids Bitswap server's rate limiting.All this brings the need to make
GetSize
as lightweight as possible, leaving actual proof computed toGet
. This PR achieves this by defining a constant max block size for every type block.🎱 mb blonks certified